Security concerns have become the key barrier to the adoption of cloud computing technologies. Security enhancements are drawn from a variety of paradigms. However, most of these are implemented as parts of the cloud systems' SLA (Service Level Agreements). It is thus difficult for the Cloud Service Providers (CSPs) to assure their customers that their advertised services, including these security enhancements, are genuinely present and performing as expected. This is a particular issue for customers who handle sensitive data or are themselves subject to strict contractual or regulatory requirements (for example, financial institutions and law firms). Consequently, effective trust establishment remains a main challenge for CSPs.
In order to address this issue, the Trusted Cloud concepts have been developed. These are built on Trusted Computing technologies which enable remote attestations to examine and confirm the genuine behaviours of a cloud infrastructure. Trusted Computing is a series of specifications defined by the TCG (Trusted Computing Group), an international industry standards group. Trusted Computing relies on a secure hardware device, the TPM (Trusted Platform Module), which is attached to a computing platform to reliably record and report the loaded software systems on the platform. The TPM is an international standard for a secure cryptoprocessor, which secures hardware by integrating cryptographic keys into devices. The TPM's relative tamper-proof nature and built-in cryptographic protocols enable it to act as a Root-of-Trust (RoT) at the base of the system. Starting from this RoT, a Chain-of-Trust (CoT) is built by iteratively attesting to the trustworthiness of the higher layers. Remote attestation is implemented to securely fetch the trust evidence (i.e. the measurement values) maintained by the RoT and reliably determine the genuine behaviours, or the properties, of every component recorded within the CoT.
Existing Trusted Cloud solutions generally employ a centralized architecture. A central attestation server (e.g. the OpenAttestation, or OAT) gathers the TPM-generated trust evidence from each node to ensure that the node has the required properties, such as deployment with the expected software components, or correct configuration. When deploying Virtual Machines (VMs) to the cloud, customers may register with the OAT the desirable properties for the expected hosting infrastructure. The OAT will in turn enforce continuous attestations to examine the VMs' correct deployment status. Customers can further attest or verify the OAT server's integrity to confirm that their VMs are secure and the services they purchased are trustworthy. However, there are many limitations with existing solutions, especially when the attestation service is scaled up.
For example, in existing Trusted Cloud deployments the central attestation server is in charge of attesting the entire infrastructure and hence has become a single-point-of-failure. Any faults will therefore inevitably disrupt the trust services, especially when more security management services are built on the trustworthiness semantics. This service will also become the main target for attackers. Any malicious insiders who have gained administrator privileges to this single service will also have more capabilities to manipulate the entire cloud's trustworthiness status.
A further limitation of existing solutions is scalability. When the central attestation server or OAT expands to serve more VMs or a larger cloud infrastructure, it quickly becomes a performance bottleneck. On the other hand, when multiple OATs are created to attest different parts of a large infrastructure, the management complexity increases because customers have to be constantly aware of the correct part for each of their VMs.
Existing solutions also often exhibit a weak chain-of-trust. In order to attest the genuine behaviours of a VM, the VM's virtual TPM (vTPM) must be linked to the underlying physical TPM (Trusted Platform Module). This means the VM's owner must be able to contact the corresponding physical TPM. However, this is particularly difficult as revealing the identities of underlying TPMs exposes the cloud's internal structure. This breaks the cloud's transparency promises and also facilitates co-location attacks. Therefore, the current OAT system does not support attestations of a VM's underlying host.
Dynamism is also an issue for existing Trusted Cloud deployments, since VMs migrate among hosts and the linkages between the vTPMs and the underlying physical TPMs are rebuilding constantly. Managing these frequent updates places an overhead on the customers. It further reveals the internal dynamisms of the cloud infrastructure. Therefore, the current OAT system does not support attestations of migrating VMs.